The mixed-version suites — compat, framework upgrade, and `k8s_test_suite`
(which runs the same `FrameworkUpgrade` test) — run genesis with default
features, which enable `HOTNESS_IN_EPILOGUE` while mainnet and testnet
still have it off. An upcoming change to how the promoted set is derived
makes old and new binaries disagree on the hotness portion of transaction
outputs when the flag is on, so pin it off to keep these suites aligned
with the networks they are meant to mirror.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Hot state promotions (the `to_make_hot` set in the block epilogue) are
part of consensus, so their inputs must be deterministic. This reworks how
that set is derived.

## Why the old derivation was problematic

Promotions were fed from BlockSTM's read/write summary, which exists for
conflict detection, not for this:

- **Path-dependent.** The summary differs between parallel and sequential
  execution (e.g. aggregator v1 reads served by delta resolution are
  dropped in parallel but kept in sequential), so the same block could
  promote different keys depending on how it happened to execute — a
  divergence in a consensus-agreed artifact.
- **Coupled to gas config.** It was only populated inside the
  `conflict_penalty_window` branch, so promotions silently depended on an
  unrelated block-gas knob.
- **Incomplete write exclusion.** Its write side misses in-place
  delayed-field rewrites, aggregator v1 writes/deltas and module writes, so
  a key the block writes could still be promoted by the epilogue even
  though the write already makes it hot.

## Approach

Record the read set at the VM boundary, where it is a pure function of the
transaction and the pre-state — identical across parallel and sequential
execution and independent of gas config:

- `StorageAdapter` records resource, resource-group, table-item, aggregator
  v1 and config reads. Respawned sessions share one recorder so all of a
  transaction's sessions accumulate into a single set.
- `ReadRecordingCodeStorage` wraps the code storage and records module
  fetches. It sits above the global module cache, so a module is recorded
  whether served from that cache, the per-block cache or storage. A
  script's declared module dependencies are recorded from the loaded
  script, so recording does not depend on the verified-script cache, whose
  warmth is execution-schedule dependent.
- A transaction's output carries the data and module keys as two
  collections; they are disjoint by construction, so consumers iterate a
  chained view and nothing pays to merge them.
- Written keys are enumerated directly from the change set, covering every
  write kind the conflict summary missed.

## Worth calling out

The new set intentionally differs from the old one — e.g. `exists<T>` now
loads the resource and counts as a read — so it ships behind the existing
hotness feature flag, which the mixed-version forge suites keep off (see
the preceding forge commit) to avoid old/new nodes disagreeing on
transaction output. Adds a per-block promotions histogram and tests
covering sequential/parallel parity, each read and write kind, script
dependencies, and discard handling. Follow-ups: read-kind/hotness tagging
and an on-chain, byte-based promotion cap.

## Performance

The recording runs unconditionally, so its per-transaction cost has to
stay small. Even a trivial transaction fetches 10+ framework modules and
re-reads the same resources across its sessions, so the hot paths are
engineered around allocation and clone traffic:

- The interpreter fetches the same module many times in a row. A
  last-recorded fast path (a reused string buffer, so module switches
  allocate nothing) skips the bookkeeping for such runs, and the
  recording wrapper's delegators are `#[inline]` so wrapping does not
  deoptimize the module fetch path.
- All recording sets are keyed by `StateKey` — which carries a
  precomputed 32-byte hash — under FxHash (via the maintained
  `rustc-hash`), pre-sized past the typical framework-module count, and
  keys are cloned only on first sighting; repeats, e.g. framework modules
  touched by every transaction, are the common case.

Measured on the single-node benchmark with interleaved paired runs,
together with the preceding `to_make_hot` ordering commit: ~2-2.5% net
mean TPS cost across representative workloads, and ~0.3-0.4us per
transaction on the sequential move-e2e micros. An ablation build with
recording no-oped attributes the entire cost to the recording machinery
itself (diffuse per-transaction set and clone work rather than any single
hot symbol) and confirms the accumulator commit offsets part of it.
Candidate follow-ups if more needs to come back: a per-thread module-key
memo to keep the registry lock off the extraction path, pointer-hashed
recorder sets (`StateKey` equality is already pointer identity), pooling
the per-transaction sets, and an indexed key registry to cut refcount
traffic on hot shared keys.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>